---
title: Validate PDF/A conformance
summary: Inspects a submitted PDF's XMP metadata to determine PDF/A conformance.
status: draft
owner: Not determined from source
last_reviewed: 2026-09-17
library: PdfAPI
reference_type: embedded
operation_id: OP-VALIDATE-PDFA
trigger: Client submits POST v1/info/validate/pdfa with PDF bytes
---

# OP-VALIDATE-PDFA: Validate PDF/A conformance

Inspects a submitted PDF's XMP metadata for a `pdfaid:conformance` value of `A` or `B` to determine PDF/A conformance.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-VALIDATE-PDFA |
| **Trigger** | Client submits `POST v1/info/validate/pdfa` with PDF bytes |
| **Entry endpoint** | [`POST v1/info/validate/pdfa`](../endpoints/info-controller.md#post-v1%2Finfo%2Fvalidate%2Fpdfa) |
| **Owning component** | `InfoController.IsPdfa(byte[])` → Syncfusion PDF/A inspection helper |
| **Inputs** | Request body: `byte[]` PDF |
| **Outputs** | Bare `bool` |
| **Failure response** | Always returns `200`; the implementation catches its own exceptions and returns `false` |

## Steps

1. The Syncfusion-based implementation inspects the document's XMP metadata for a
   `pdfaid:conformance` value of `A` or `B`.

   This inspection logic is implemented in `PdfApi.SyncFusionCore`; see the [PdfApi.SyncFusionCore library documentation](../../../libraries/pdfapi-syncfusioncore/index.md) for the library's full operation and API reference (no single dedicated operation page covers this specific conformance-inspection helper). Its behavior is summarized here only as observed on this request path.

   > **Origin:** The XMP-metadata PDF/A conformance inspection described in this step is
   > implemented in `PdfApi.SyncFusionCore`, not in `PdfAPI`. See the linked library
   > documentation for further delegated-logic context.
2. If the metadata inspection throws (e.g. malformed or non-PDF input), the implementation
   catches its own exception and returns `false` rather than propagating.
3. The bare `bool` is returned — HTTP `200`.

## Process flow

The following diagram shows the metadata-inspection and internal-catch sequence.

```mermaid
flowchart TD
    A["POST v1/info/validate/pdfa"] --> B["Inspect XMP metadata<br>for pdfaid conformance"]
    B --> C{"Exception during inspection?"}
    C -->|Yes| D["Caught internally, return false"]
    C -->|No| E["Return conformance result"]
    D --> F["200 OK"]
    E --> F
```

## Transaction and side effects

| Aspect | Finding |
| --- | --- |
| Unit of work | None |
| Commit point | Not applicable — no database access |
| Records written | None |
| Downstream calls | None |
| Repeat-call behavior | Read-only; safe to repeat |

## Logging

| Surface | Written content |
| --- | --- |
| — | No dedicated logging observed on this path |

## Error handling

- No error status codes are identified on this path — the implementation catches its own exceptions and returns `false`.

## Related documentation
- [API index](../index.md)
- [Overview](../overview.md)
- [Architecture](../architecture.md)
- [Endpoints](../endpoints.md)
- [Authentication and authorization](../authentication-authorization.md)
- [Dependencies](../dependencies.md)
- [Configuration](../configuration.md)
- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [Data model](../data-model.md)
- [Operational runbook](../operational-runbook.md)
- [Tech debt](../tech-debt.md)

## Sources
- PdfAPI\Controllers\v1\InfoController.cs
- PdfApi.SyncFusionCore\PdfHelper.cs